Skip to main content

​
Workflow Parallel Template

The Workflow Parallel template demonstrates how a BindAI workflow can branch into multiple outgoing paths and synchronize those paths using a Join node. The Parallel node provides the branching point. The workflow executor schedules the outgoing nodes, while the Join node tracks how many branches have arrived before allowing execution to continue. This template introduces parallel branching and synchronization.

​
Purpose

This template demonstrates how to:
  • create multiple workflow branches
  • schedule independent workflow paths
  • synchronize branches with a Join node
  • use shared workflow context across branches
  • coordinate independent operations

​
Workflow Structure

A typical parallel workflow looks like this:
The Parallel node creates the branching point. The Join node provides synchronization after the branches.

​
Execution Flow

The workflow first reaches the Parallel node:
The Parallel node itself does not execute the branches. Instead, the workflow executor schedules every node in the Parallel node’s outgoing next_nodes. Conceptually:
Each scheduled branch then proceeds through the normal workflow execution system.

​
Parallel Node

A Parallel node can be created with:
The node does not require a predicate or branch-specific configuration. Its execution simply returns the existing workflow context. The executor determines what happens next from the node’s outgoing connections.

​
Independent Branches

Parallel branches are intended for operations that can progress independently. For example:
These operations do not require each other before they begin. A dependent workflow should instead use sequential nodes. For example:

​
Join Node

A Join node can synchronize the branches. It is configured with the number of expected arrivals:
For three branches, the Join waits until all three have reached it.

​
Synchronization

The Join node stores its arrival count in the shared workflow context. Conceptually:
After another branch arrives:
When the expected count is reached:
The Join then allows execution to continue.

​
Waiting

If fewer branches have arrived than the configured expected value, the Join sets:
The executor recognizes the waiting state and pauses normal workflow progression. Once the final expected branch reaches the Join:
The workflow can continue.

​
Shared Workflow Context

All branches use the workflow’s shared context. For example:
This means branch outputs can be stored in workflow variables. A recommended pattern is:
After the Join:
are available through the shared workflow context.

​
Combining Results

The Join node does not combine or transform branch results. Its responsibility is synchronization. For example:
The Summary Agent or another downstream node can use result_a and result_b to produce a combined result.

​
Example

A simple multi-agent workflow could be structured as:
The Join ensures that the expected branch arrivals have occurred before the Summary Agent is reached.

​
Parallel vs Sequential

Parallel branching is useful when operations are independent.

​
Sequential

​
Parallel

Sequential execution is preferable when tasks have direct dependencies. Parallel branching is useful when tasks can proceed independently.

​
Error Handling

The Parallel and Join nodes do not implement their own branch-specific failure strategy. Node exceptions are handled by the workflow executor. If a retry policy is configured, the executor can retry a failing node until the configured retry limit is reached. If the node continues to fail and the retry policy is exhausted, normal workflow failure handling takes over. Therefore, this template should not imply that failed branches are automatically isolated or that successful branches are automatically converted into partial results.

​
Related Workflow Features

Parallel workflows can be combined with other workflow features. For example:
Retry and timeout behavior belongs to the executor and node configuration rather than to the Parallel node itself.

​
Typical Use Cases

This template is useful for:
  • multiple independent agents
  • independent API operations
  • separate document analysis
  • multiple retrieval operations
  • validation from different sources
  • independent data preparation
  • workflows that converge several results

​
Best Practices

  • Use parallel branches only for independent operations.
  • Use a Join when branches must synchronize.
  • Set expected to the number of branch arrivals required.
  • Store branch-specific results in separate variables.
  • Avoid conflicting writes to shared workflow variables.
  • Keep dependent operations sequential.
  • Use retry configuration for transient node failures.
  • Remember that the Parallel node itself does not create separate workflow contexts.
  • Keep branch structures simple and easy to maintain.

​
Summary

The Workflow Parallel template demonstrates BindAI’s parallel branching model. A Parallel node provides a branching point, while the workflow executor schedules its outgoing nodes. A Join node synchronizes the branches by counting arrivals against its configured expected value. Until the expected number of branches arrives, the Join places the workflow in a waiting state. Branches share the workflow context, so separate output variables should be used when independent branches produce separate results. This pattern provides a clear way to build branching workflows that later converge at a synchronization point.